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Hypersonic Research Vehicle (HRV) Real-time Flight Test Support 
Feasibility and Requirements Study 

Part II - Remote Computation Support for Flight Systems Functions 


1.0 Summary 

This report assesses the requirements for the use of remote computation to support HRV 
flight testing. First, we develop remote computational requirements to support functions that will 
eventually be performed onboard operational vehicles of this type. These are functions which 
either cannot be performed onboard in the time frame of initial HRV flight test programs because 
the technology of airborne computers will not be sufficiently advanced to support the 
computational loads required, or it is not desirable to perform the functions onboard in the flight 
test program for other reasons. Second, we address remote computational support either required 
or highly desirable to conduct flight testing itself. We propose the use of an Automated Flight 
Management System which is described in conceptual detail. Third we discuss autonomous 
operations and finally, unmanned operations. 

In this structure, computational support is discussed for trajectory optimization, energy 
management and flight test management and control. The use of trajectory optimization is 
considered essential to successful preflight planning and inflight replanning for HRV operations 
and flight tests. The type of trajectory optimization required is computer generated open loop 
control time history solutions to nonlinear two-point boundary value problems. This type of 
trajectory optimization is computational very intensive. It is not possible in airborne computers 
today to generate solutions to the class of global optimization problems we are interested in for 
HRV's within reasonable solution time constraints. Continuous energy management during HRV 
flight is essential for a number of reasons. For replanning and safety reasons it is essential to 
know on a continuous time basis where the vehicle can go from its present operational state 
(location, fuel state, altitude, velocity, etc.). This is required to assure safe vehicle recovery at 
alternate landing sites in the event of flight emergencies, and to assist in replanning in real time. 
We must guard against generating a replan which is impossible from an energy management 
viewpoint to execute. Also, continuous energy management is required as a prerequisite to real 
time use of trajectory optimization. An optimization algorithm will fail when faced with a problem 
for which there is no solution which, in turn, will add significantly to solution times and possibly 
require human intervention in the solution process. Finally, it is highly desirable to provide 
automated flight test management and control in the form of an advanced Automated Right Test 
Management System (ATMS). Such a system would provide knowledge-based expert system 
supervision of trajectory optimization algorithms, trajectory generators, trajectory controllers, 
simulations and models. It would provide a total environment for preflight planning and inflight 
monitoring. 

The bottom line is that remote computational support is required to attain the necessary 
operational flexibility to conduct a flight test program which minimizes testing costs and time. It is 
not acceptable to operate an HRV in a space shuttle mode in which very little flexibility in the 
preplanned mission and timeline is allowed. It is most desirable to operate the vehicle in a mode 
which more closely parallels that of a high performance aircraft wherein the mission can be 
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replanned in real time to accommodate data, system, human or timeline anomalies in the preplanned 
mission. 


2.0 Introduction 

The NASA Ames Research Center, Dryden Flight Research Facility (Ames-Dryden), has a 
unique real-time flight test support and research capability provided by the Western Aeronautical 
Test Range (WATR) and the Remotely Commanded Vehicles and Display (RCVD) facility. The 
WATR consists of the mission control center, communications systems, real-time processing and 
display systems and tracking systems O)- The real-time data processing and display systems of the 
WATR, for example, provide high level flight test information on appropriate engineering 
parameters®. An advanced example of this was the monitoring of the X-29A flight tests^) as 
illustrated in Figure 1. During the initial portion of the program, telemetry data were relayed from 
Edwards, California to Bethpage^New York for the Grumman Engineers to be involved in the real- 
time flight test monitoring. The RCVD facility provides real-time ground-based computational 
support for test aircraft command, control and display functions through use of telemetry, ground 
based computers and uplinks^ . The RCVD facility has been used, for example, to perform flight 
controls experiments with the control laws computed on ground-based computers. SPARTA Inc., 
with the assistance of Systems Technology, Inc. and Information Management, Inc., performed a 
study* 4 * for Ames-Dryden considering a major expansion of the real-time support capabilities of 
these facilities that could significantly enhance flight research. The study reported here is an 
extension of that study addressing specifically the flight testing of a Hypersonic Research Vehicle 
(HRV). The study was conducted in three Parts: Part I - Real-time Flight Experiment Support 6 )-, 
Part II - Remote Computational Support for Flight Systems Functions, reported herein; and, Part 
in - Automated Flight Test Management System (ATMSpl 



GAIN AND PHASE MARGINS 

Figure 1: Stability Margins of the X-29A Were Estimated in Real-time 

Using Remote Computation 
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The HRV can be thought of as a generic form of the X-30, the experimental flight vehicle 
in the National Aerospace Plane (NASP), for the purpose of this investigation. By that we mean it 
is a hypothetical hypersonic vehicle with the same objectives as the X-30 as identified in the open 
literature. No specific NASP or X-30 data are used in this study. The class of technology 
necessary for the X-30 are considered and assumptions are made about likely design features and 
operational characteristics. This "generic" approach seems adequate for investigating this remote 
computational flight test support concept. 

Figure 2 illustrates the general concept of remote computation for real-time flight test 
support of a HRV. A high data rate telemetry system provides the down link from the HRV and 
contains all the necessary raw and/or preprocessed flight data. Accurate space positioning data are 
obtained from a combination of tracking, GPS and onboard systems. These data are provided to 
the mission control center and the real-time computation center. The real-time computation center 
would contain an extensive array of computers to support conventional processing, parallel 
processing symbolic processing, etc. These computers would operate in real-time on flight data, 
pre-stored data and simulations of the physical processes being investigated to provide a high level 
of information to assist those conducting the flight tests. The information generated would be used 
to monitor flight safety, manage the flight tests, assess the quality of the test data, control the 
experiment, and perform certain flight system functions that would normally be done onboard. Up 
links would be used to transmit guidance and control information to the HRV. 



Figure 2: Remote Computation Concept Could Improve the 
Real-time Flight Test Support of a HRV 
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Figure 3 shows how this might be done over an extended range. Computations may be 
required at three levels: (1) onboard; (2) "local" remote; and, (3) primary remote. Only the highest 
bandwidth computations and flight critical functions would be done onboard. Medium bandwidth 
non-flight-critical computation that would not tolerate the time delay going to and from the primary 
computation facility could be performed in a remote but closer location. The bulk of the support 
remote computations would be performed at the primary location where, presumably, the 
operational control also resides. An extensive master electronic data base at the primaiy site would 
contain the experimental flight data (and possibly ground generated) for easy access by NASA 
Centers and other laboratories and aerospace companies. Research Centers located around the 
country, such as Langley Research Center (Langley), Ames Research Center at Moffett Field 
(Ames), and Lewis Research Center (Lewis) could be tied into the primary site through satellite 
data links such as the NASA Program Support Communications Network (PSCN) satellite, as 
shown in Figure 4. Researchers at these facilities could be actively involved in monitoring their 
experiments during the flight. Each of the remote Centers would have their own electronic data 
bases and potentially "real-time" flight test support computations relevant to their specific 
experiment. The master and distributed data buses will have compatible formats for easy exchange 
of data. This part of the study was not to consider the range implementation issues. 


FLiGHT- CRITICAL 

COMPUTATIONS 

ONBOARD 

(HIGH BANDWIDTH) 



PRIMARY COMPUTATIONS 
AND OPERATIONAL CENTER 

• Trajectory Control 

• Energy Management 

• Low Bandwidth Mission Functions 

• Flight Safety Monitoring 

• Experiment Monitoring and Control 

• Test Data Real-Time Computations 

• Distribution to Other Research Centers 

• Electronic Data Base Accessible by 
Multiple Authorized Users 


Computations for 
Medium Bandwidth 
Mission Functions 


REMOTE 

MONITORING 


Figure 3: An Extended Range Concept for Real-Time 
Flight Test Support for a HRV 
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AMES/MOFFETT 


Figure 4: Real-time Flight Test Data Distribution Brings Other 
Centers into Active Monitoring Role 


2.1 Part II - Remote Computation Support for Flight Systems Functions 

Ames-Dryden has demonstrated the feasibility and benefit of performing certain flight 
systems functions in flight experiment programs through remote computations (e.g., F-8 DFBW 
controls research, HiMAT, and projections for HIDEC ). Many of the flight systems functions 
that would be needed for the HRV could potentially be performed through remote computation and 
off-load the onboard computation requirements. If that could be done, there would be two 
significant benefits. First, the onboard system could be minimized without compromising the 
functional objectives. The savings in weight and space could be significant. Secondly, the level of 
technology from an algorithmic standpoint that could be investigated in flight, would not be tied to 
specific flight-qualified hardware/software systems. For example, advanced architectural 
computers required for performing certain autonomous operations functions may not be available 
in compact flight-qualified versions in time for a HRV flight test program One would only have to 
have the necessary sensors and pilot interface media onboard the vehicle and perform the 
computations on the ground with this approach. Concepts could be investigated in flight ten years 
before flight qualified equipment is developed. The remote computational approach would allow 
multiple concepts to be evaluated rather than just one since it would not be locked in by the specific 
onboard hardware configuration. 
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A second way in which "remote computation" for flight systems functions can be beneficial 
for HRV flight testing is the preflight planning, replanning during the flight and precise trajectory 
guidance and/or control (manned or unmanned operations) in support of the flight test program. 
Whereas the first class of applications discussed above deal with using the remote computational to 
investigate algorithms that would eventually be implemented onboard in an operational vehicle, this 
class is directed totally at ground based computations to aid the flight test engineers and/or to 
provide command guidance to the pilot during the experimental flight test program. Remote 
computations with uplinks to the vehicle could be used in an operational situation if adequate 
onboard backup systems are provided to take over if the data links are lost or autonomous 
operations are required. The study did not treat this potential operational situation. 

Part II is to study the feasibility and develop the preliminary requirements for remote 
computational support for: 1.) certain (onboard) flight systems functions (ones that would 
normally be performed by dedicated onboard hardware/software systems generally involving 
sensors, extensive computations and in some cases pilot interfaces, e.g., displays and controls.); 
2.) flight test management and control functions to aid the flight test engineer or pilot; and, 3.) 
unmanned operations. The principal aspects of each of these that are considered here for 
illustrative purposes are trajectory guidance and control (G&C) and energy management. 

The report first defines the HRV characteristics and flight test and assumptions made, then 
addresses each of the three types of support mentioned above and finishes with conclusions and 
recommendations. 


3.0 HRV Characteristics and Assumptions 

For the purpose of this study, the HRV is assumed to be a "generic" form of the X-30; that 
is, it has the performance capability to meet the design goals of the X-30 indicated in the open 
literature^ 8 ). Its objective is to have the capability to take off horizontally, accelerate to high 
hypersonic Mach numbers using airbreathing propulsion, fly into low Earth orbit, reenter the 
atmosphere and descend to a powered horizontal landing. Since such a vehicle has not yet been 
designed, a number of assumptions must be made about its potential characteristics in order to 
perform this study®- 10 *. It is assumed to have an airbreathing multi-mode propulsion system which 
is integrated into a highly swept delta wing-body configuration of the nature shown in Figure 5 
(illustrative only). At hypersonic speeds, the propulsion mode is a liquid hydrogen burning 
scramjet. A rocket engine is assumed for the de-orbit maneuver. The HRV structure is assumed to 
be a hybrid of advanced materials, fabrication techniques, hot structures and actively cooled 
structures. It may contain advanced metallic alloys, inter-metallic composites, metal-matrix 
composites, advanced carbon-carbon composites, ceramics and ceramic matrix composites. 
Portions of the structure, such as the nose cone leading edges and the engine cowl, are expected to 
require some form of action cooling using liquid hydrogen. 

Once the HRV reaches the speed where the scramjet takes over, it must fly a corridor of 
dynamic pressure between the minimum required to sustain engine operation (plus some margin) 
and the maximum allowable due to flutter, structural and/or aerothermodynamic loads limits. The 
scramjet has the best performance flying at maximum dynamic pressure, about 1,500 pst for this 
class of vehicles. At that dynamic pressure the surface temperature could reach 2,000°F. The heat 
flux into the structure from aerodynamic heating is sensitive to the boundary layer transition point 
as well as dynamic pressure, both of which are functions of the flight conditions. Precise control 
of the flight path trajectory will be very important 
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ADVANCED AVIONICS 



MAX TAKEOFF WEIGHT: 200,000 lbs. 


Figure 5: HRV Will Require Multiple Advanced Technologies 


4.0 HRV Flight Test Assumptions 

The flight test program is assumed to be conducted from Edwards Air Force Base (EAFB). 
The HRV would take off horizontally, fly a preplanned trajectory up to a preplanned maximum 
Mach number and altitude then return on a preplanned trajectory to EAFB and land horizontally. 
Figure 6 is an example of what a typical ground-track might look like during the envelope 
expansion phase. The Figure shows one potential method^ 5 ) for maintaining continuous telemetry 
and uplink coverage by using relays via mobile remote ground units and a remote airborne 
platform. A satellite relay may be needed for the highest performance flight conditions. The range 
considerations for providing telemetry coverage was included in this part of the study. It is 
assumed here that it is possible to have telemetry coverage at the flight conditions of interest. 
Efforts of potential time delays using relay stations are discussed. 

It is assumed that the flight test program would progress in the typical experimental aircraft 
manner of gradual envelope expansion. For example, the first phase would be low-speed tests 
with the turbojet engine (mode) to check out many of the systems, subsystems, instrumentation, 
telemetry, flying qualities, landing characteristics and performance would be confirmed before 
proceeding to less certain hypersonic speeds and scramjet (mode) operation. Extensive flight 
simulation and analyses, updated at each step by flight test data, would support this envelope 
expansion. It is assumed that there would be an extensive pre-flight data base on all disciplinary 
aspects of the HRV and that it would be updated with test data from each flight. The key point for 
this study is that as long as the HRV is close to the planned trajectory and flight test plan on each 
flight, you are only making modest extrapolations from a known data base. 
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HRV HORIZONTAL TAKEOFF AND LANDING AT EDWARDS ? 
MAX MACH NUMBER OF 10 AT 100,000 FT. ALTITUDE 
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Figure 6: Typical Ground Track for an HRV Flight Test 
4 . 1 Instrumentation 

The flight test instrumentation is, of course, critical to the real-time monitoring and control 
process. It is often difficult if not impossible to measure a parameter you want where you want it. 
The problem will be particularly difficult in hypersonic flight with scramjet propulsion. The NASP 
program recognizes this and has one element of the program devoted to developing instrumentation 
concepts for the most challenging problems. In performing this study, certain assum ptio ns had to 
be made about instrumentation and measurement techniques which should be available for a HRV. 
For example, w e do not address the measure ment of free-stream flow field conditions, i.e., static 
and dynamic pressure, Mach number, etc., but rather assume that accurate measurements of those 
parameters are available. We assume that the typical state and control variable measurements are 
available via telemetry as well as range data from the NASA tracking facilities. Other vehicle and 
systems parameter measurements, such as vehicle configuration, fuel status and flow rate, critical 
structural temperature and total stress, etc., are assumed available on the ground. 


5.0 "On Board" Flight System Functions 

In this section we develop the remote computational requirements for functions that will be 
eventually performed onboard operational flight vehicles. We will show that these functions are 
important for the flight test and that they cannot be implemented on today’s generation of airborne 
computers and are not likely to be implementable in time to be incorporated into the first HRV fligHt 
tests. In addition, it is likely that as time goes on, the demands for computational power to 
implement increasingly advanced concepts will increase. Of course, the capabilities and 
performance of airborne computer hardware will also increase in parallel. In fact, it can be shown 
that for the past twenty years computer throughput has doubled every year for a fixed physical 
CPU size. Figure 7 illustrates this phenomenon. The Figure shows the increase in integrated 
circuit density as a function of time since 1960. The phenomenon is not likely to change for the 
foreseeable future. 
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Figure 7: Integrated Circuit Density is Doubling Every Year 

It is also a well observed phenomenon that the computational demands of advanced 
concepts arising out of research and development activities always exceed current computer 
hardware capabilities. In other words, there will always be the need to use remote computation to 
demonstrate increasingly advanced functions no matter how capable airborne computers become. 
The assumption here, of course, is that ground based computing systems will always be able to 
support more throughput than airborne computers because of the unlimited space available in a 
ground based system and the lag between applying the latest computer technology to ground based 
general purpose computers and airborne special purpose computers. This lag is typically two to 
six years and is a function of market demand (very low for airborne computers), commercial vs. 
government application (commercial applications are much more financially rewarding to a 
developer), and the necessity to flight qualify and flight harden all airborne computer equipment. 

In addition, remote computation allows the implementation of advanced concepts in code 
which does not have to meet stringent V&V requirements and which can be modified 
comparatively easily. 

In the following sections, we develop the rational and requirements for remote computation 
to support three types of onboard flight system functions; trajectory optimization, energy 
management and autonomous operations. 
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5.1 Trajectory Optimization 


From a computational viewpoint,trajectory optimization is by far the most demanding of 
G&C functions. We consider the generation of energy management trajectories to be trajectory 
optimization problems from this computational viewpoint. We formulated two trajectory 
optimization problems which are appropriate for the HRV and for potentially illustrating the 
benefits of the remote computation approach. We surveyed ARC, LaRC and othersources for 
existing optimization algorithms for solving the problems formulated and identifiedrcvo leading 
candidates (POST 11 ) and OTIS' 121 ) suitable for use in generating optimal trajectories for the HRV. 
We studied these algorithms to assess the computational requirements for real-time optimization 
solutions. 


5.1.1 Trajectory Optimization Definition & Requirements 

It is our view that an HRV must have access to highly developed trajectory optimization 
algorithms and the necessary computing power to exercise these algorithms in real time for inflight 
replanning. The purpose of these algorithms would be to generate flight trajectories which the 
HRV would follow to accomplish some goal. First, let us define what we mean by trajectory 
optimization. 

The class of problems we are considering in trajectory optimization in this application is the 
deterministiCjnonlinear, two-point boundary-value class of problems. We seek computer generated 
numerical solutions for optimal control time histories and their associated flight trajectories which 
minimize (or maximize) some performance measure (a functional which might include time, control 
energy, etc) subject to equality constraints (the dynamic equations of motion of the flight vehicle), 
state inequality constraints (limitations on vehicle states such as angle-of-attack, load factor, 
dynamic pressure, Mach number, aero-heating, etc.), control inequality constraints (limitations on 
thrust, control deflections or forces, etc) and boundary conditions. The equations of motion 
cannot be linearized typically because the range of operating conditions encountered is too large in 
a given problem. In addition the inequality constraints play a heavy roll and prevent for all 
practical purposes the linearization of the problems of interest. Thus, an optimal control law 
solution cannot be generated analytically, e.g., through solution of a Riccati equation. If we could 
generate an optimal control law (controls which are a weighted linear combination of vehicle states) 
or even a family of optimal control laws, the problem would be over. We could do all trajectory 
optimization on board the flight vehicle. There would be no need for remote computation to do 
trajectory optimization. 

Also, we are not talking about the class of problems here which are concerned with 
tracking a trajectory once one is generated. The tracking problem can also be formulated as an 
optimal control problem. In this application, it is the stochastic optimal linear feedback problem: an 
extension of the linear regulator with a quadratic performance measure which minimizes tracking 
errors and control energy. An optimal control law is generated and the computations can be done 
on board a flight vehicle as we shall see. This is the correct application of optimal control theory 
for the problem discussed in section 5.1.6 below. 

The dynamic equations of motion used in trajectory optimization problems of the type 
discussed herein are typically of the 3 degree-of-freedom (DOF) variety with pseudo degrees-of- 
freedom added to better simulate limitations on angular rates, which we will term 3 DOF+. 
Typically these pseudo degrees-of-freedom take the form of first order lags in parameters such as 
roll rate, pitch rate, yaw rate, thrust rate of change, etc. Occasionally, a trajectory optimization 
problem requires the use of a full 6 DOF simulation to obtain acceptable results. Since these 
optimizations require a great deal of computer CPU time typically, it is wise to use only the level of 
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model sophistication required to generate a meaningful solution (optimal control time history and 
associated trajectory). Using this solution as the norm, the stochastic optimal linear feedback 
problem can then be formulated by linearizing the equations of motion about the norm and solving 
a Riccati equation to generate a tracker optimal control law (section 5.1.6). This control law 
produces control increments which must be added to the control time history at any given point in 
time to yield the total control deflections or forces. 

Historically, trajectory optimization methods have been successfully usd 1 in a wide variety 
of applications including off-line non-real time trajectory optimization for flight vehicles. The most 
common methods in existence are: 

1) First order gradient methods (the method of steepest descent) 

2) Second order gradient methods (Newton-Raphson) 

3) Variation of exteremals 

4) Quasi-linearization 

5) Dynamic programming 

6) Epsilon methods 

A number of algorithms a re. available in the aerospace industry, commercially, in the academic 
world and in government which employ all of these techniques. In section 5.1.3 we discuss two 
of the most promising for the HRV application. In addition, work is in progress at Honeywell to 
develop real-time trajectory optimization algorithms. 

The primary requirement of a suitable trajectory optimization program to qualify it for use 
in HRV flight testing is that of flexibility. The algorithm must be able to generate optimized 
trajectories for an extremely wide range of performance measures, flight conditions, and 
constraints. A large variety of flight test maneuvers will be formulated involving energy 
management, envelope expansion, capture maneuvers, structural maneuvers, aerodynamic heating 
tests, stability and control tests and many others. In addition the data base used by the simulation 
in the program must be easily accessed so that new data can be input daily during the flight test 
program. Finally, the program must be able to generate trajectories rather quickly on available 
computer systems so that real-time trajectory optimization can be effectively performed during a 
flight test in response to some flight anomaly. 

As an example of the complexity of HRV flight testing as opposed to standard high 
performance flight testing,consider the case of executing a simple capture maneuver from the end 
condition of one maneuver to a trim point for the next maneuver. In an F- 18, the capture maneuver 
is performed manually with little consideration other than normal operating procedures to the flight 
path chosen to perform the capture. It is easy to design a flight test trajectory controller to perform 
the maneuver automatically. This was done in the ATMS^ program. No optimization was 
involved. In the HRV the flight path chosen to perform the capture is a major problem - an 
optimization problem. Many constraints and limitations are involved including aerodynamic 
heating, Scramjet operational limits, major concerns about fuel consumption, operating area 
considerations, etc. It cannot be left to the test pilot to simply fly to and stabilize on the next trim 
point. 


Trajectory optimization will be required to perform in-flight replanning. The replanning 
requirement arises out of the desire to be able to generate revised trajectories in response to flight 
test anomalies such as data dropouts, instrumentation failures, unexpected data, vehicle 
emergencies, vehicle system failures which are not emergencies but which affect the remaining 
time line, weather, scheduling conflicts (particularly with air-route traffic), fuel consumption 
anomalies and many other factors. Replanning must be accomplished fast. We envision that real 
time trajectory optimization algorithms must be able to generate solutions in five to ten seconds of 
CPU time. 



5.1.2 


Example Problem Formulations 


The two optimization problems formulated are given below: 

1 . HRV Reentry 

This problem involves HRV reentry trajectory analysis. It is a derivative of sample 
problem 2 formulated in Reference 1 1. The simulation is initiated at the entry interface at 
400,000 feet geopotential altitude and terminated when the vehicle has descended to 50,000 
feet geopotential altitude. The trajectory control time history attempts to minimize total heat 
flux by capitalizing on an assumed capability of the thermal protection system to withstand 
a high heat rate for a short period of time. This assumption is based on a similar design on 
the space shuttle. The basic optimization strategy is to attain the prescribed maximum heat 
rate as early as possible on entry into the atmosphere. This limit is followed until an 
acceleration constraint is encountered. A bank angle linear-feedback steering algorithm is 
then switched from controlling heat rate to controlling the acceleration profile. The 
acceleration limit is then followed until it is necessary to deviate from the limit to achieve 
the specified crossrange. 

2. Minimum Fuel Acceleration from Mach 5 to Mach 20 

This problem involves an acceleration from a low hypersonic Mach to a high 
hypersonic Mach at a high altitude. The altitude is not constrained to be constant during the 
maneuver. The algorithm attempts to maintain dynamic pressure within specified limits and 
keeps the stagnation point heat flux below some maximum while minimizing the fuel 
required to perform the maneuver. 

These two problems are similar to the sample problems in Reference 11. We extrapolated 
from the results of running the sample problems given in Reference 1 1 (which are totally suitable 
for the space shuttle) to estimate the throughout required to run the above problems in a variety of 
computers. 


5.1.3 Trajectory Optimization Algorithms 

The purpose of this work was to identify the best possible, available algorithms for 
performing the optimizations and determine the relative merits, capabilities and disadvantages of 
each. Of all the available optimization algorithms reviewed, two emerged as having the necessary 
capabilities and performance. Both developments were government sponsored and the algorithms 
with documentation are available from COSMIC at nominal cost. They are: 

1 . Program To Optimize Simulated Trajectories (POST) 

2. Optimal Trajectories By Implicit Simulation (OTIS) 

Both OTIS and POST have the capability of generating trajectories under a very wide 
variety of conditions, constraints, performance measures. This is an absolute requirement if they 
are to be suitable for use in HRV flight testing as discussed in section 5.1.1. 


5. 1.3.1 POST 


1 2 



POST^ 11 ) was designed, developed, coded and delivered to NASA Langley by Martin 
Marietta Corporation. It is a generalized point mass, discrete parameter targeting and optimization 
FORTRAN program. POST provides the capability to target and optimize point mass trajectories 
for a powered or unpowered vehicle near an arbitrary rotating, oblate planet. POST has been used 
successfully to solve a wide variety of atmospheric ascent and reentry problems, as well as 
exoatmospheric orbital transfer problems. The generality of the program is evidenced by its N- 
phase simulation capability which features generalized planet and vehicle models. This flexible 
simulation capability is augmented by an efficient discrete parameter optimization capability that 
includes equality and inequality constraints. 



Figure 8: Rosen's Gradient Projection Automatically Treats 
Inequality Constraints 

The optimization routine used by POST is a modified first order gradient projection method 
of Rosen< 15 ) . The technique is shown for a simple two parameter function optimization in Figure 
8. The function f(x,y) is to be minimized with two inequality constraints active. Within the 
admissible region we minimize in the direction of the maximum negative gradient, however, on a 
constraint boundary we project the maximum negative gradient at that point onto the boundary to 
obtain the direction of minimization, etc. 
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Rosen's gradient projection is an excellent technique ideally suited to a generic nonlinear 
trajectory optimization algorithm because it handles inequality constraints in a very natural way and 
has excellent convergence properties. 

5. 1.3. 2 OTIS 

OTIS< 12 > was designed, developed, coded and delivered to the Air Force Wright 
Aeronautical Laboratories by Boeing Aerospace Corporation. OTIS is a FORTRAN program for 
simulating and optimizing point mass trajectories of a wide variety of aerospace type vehicles. The 
program is designed to simulate and optimize trajectories of launch vehicles, aircraft and missiles 
with provision made for cruise legs, flight in a low air density environment, free and fixed end 
constraints, specified waypoints and path constraints. OTIS was developed to provide an easy to 
use trajectory analysis tool. OTIS was assembled using a modular architecture to facilitate program 
upgrades and modifications. OTIS can be used to solve optimal control problems without 
extensive optimization expertise. 

The optimization technique used in OTIS is a nonlinear gradient projection method similar 
to that employed in POST. 


5. 1.3.3 Others 

Other algorithms considered included a number of available dynamic programming 
algorithms, an algorithm featuring Balakrishnan's Epsilon Method^ 13 ), and the COPES algorithm^ 14 ) 
featuring a conjugate direction method by Fletcher and Reeves. None of those considered had the 
extensive simulation, modeling and optimization feasibility and environment provided by OTIS and 
POST. 


5.1.4 Computation Requirements 

The most demanding requirement for performing trajectory optimization in real time for 
inflight replanning is computer throughput. In turn, this requirement dictates whether one can 
perform real-time trajectory optimization in an onboard airborne computer in time for 
implementation in a prototype HRV or whether it must be done on ground computers in a remote 
computation mode. With this in mind a computer throughput study was performed based on using 
OTIS and POST as the optimization algorithms. 

POST and OTIS were installed in a MicroVAX n at SPARTA's Laguna Hills Office. The 
sample problems supplied with both programs were run and CPU times were recorded. POST is 
supplied with three sample problems involving trajectory optimization on a space shuttle ascent, a 
reentry and an orbital transfer. OTIS is supplied with six sample problems ranging from a 
minimum time-to-climb for a supersonic fighter to an air launched LTSAT problem. The sample 
problems described in section 5.1.2 were not run per se: rather, a comparison was made between 
the problem formulations for the sample problems supplied with each program and the problems 
described in section 5.1.2. An extrapolation was then made to estimate CPU run times for these 
problems on the MicroVAX II. These estimates were further extrapolated to estimate run times on 
other machines of arbitrary throughput in terms of MFLOPS. Table 1 shows the CPU run times of 
the sample problems supplied with POST and OTIS on the MicroVAX II, a 0.9 MFLOP machine. 
The table also shows the extrapolated CPU run times for these sample problems on several other 
computers suitable for remote computation available at NASA Ames Dryden including a 
MASSCOMP 5400, a CYBER 750, an ALEXI 6400 and a SEL 32/97. In addition, a transputer 
based configuration of 100 advanced transputers is included. Extrapolated run times for three 



airborne computers are also shown including a Nordon MILVAX, a Rolm HAWK and a transputer 
based computer with 16 advanced processors. In the case of the transputer based systems 50% 
parallelism is assumed to be achievable. We consider the MILVAX and the HAWK because they 
are flight qualified general purpose computers specifically built for onboard computation. We 
consider a transputer based computer because transputers allow parallel processing architectures to 
be constructed which are very high in throughput (assuming one can take advantage of the 
parallelism available), very low in cost and configurable in terms of size, shape and the number of 
processors installed. In addition, NASA has a project ongoing to build and flight qualify a 
transputer based computer for flight test use onboard a flight test aircraft 


Table 1 

CPU Times (minutes) for Sample Problems Supplied With The Programs 

Remote Computers Airborne Computers 



Micro 

VAXE 

MC 

5400 

CYBER 

750 

ALEXI 

6400 

SEL 

32/97 

T-xxx* 

(100-50%) 

MIL 

VAX 

HAWK 

T-xx: 

(16-5 

MFLOPS 

0.9 

2.5 

11 

5 

10 

200 

2 

1.4 

32 

POST 

Prob. 1 6D 

6.1 

2.2 

0.5 

1.1 

0.5 

0.03 

2.7 

3.8 

0.17 

Prob. 1 3D 

6.9 

2.5 

0.6 

1.2 

0.6 

0.03 

3.1 

4.3 

0.19 

Prob. 2 3D 

4.7 

1.7 

0.4 

0.8 

0.4 

0.02 

2.1 

2.9 

0.13 

Prob. 3 3D 

36.3 

13.1 

15.0 

6.5 

3.3 

0.16 

16.3 

22.5 

1.00 

OHS 

Prob. 1 

13.0 

4.7 

1.1 

2.3 

1.2 

0.06 

5.9 

8.1 

0.37 


* Note: Assumes 25 board advanced (second generation) transputer computer CPU (100 

transputers) with 50% parallelism achieved 

* *Note: Assumes 4 board advanced (second generation) transputer computer CPU (16 

transputers) with 50% parallelism achieved 

The sample problems supplied the programs are formulated briefly below: 

POST 6P 

Problem 1: This problem optimizes a reentry trajectory segment (10 seconds) for a shuttle 

orbiter vehicle. The optimization strategy is to attain a prescribed maximum heat 
rate as soon as possible. 

POST 3D 

Problem 1: This problem is a shuttle ascent optimization problem to determine maximum 

payload capability of various configurations. 

Problem 2: This problem optimizes a shuttle orbiter entry from 400,000 feet to 50,000 feet. 

The optimization scheme attempts to minimize total heat by capitalizing on the 
ability of the thermal protection system to withstand a high heat rate for a short 
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period of time. The strategy is to achieve maximum heat rate as early as possible in 
reentry. 

Problem 3: This problem optimizes the location, duration and attitude of two thrusting 

maneuvers that transfer an orbital vehicle from a near-Earth parking orbit to a near- 
geostationary orbit. 

OTIS 3D 

Problem 1 : This is the traditional minimum time-to-climb problem for a supersonic fighter. 

Table 2 shows extrapolated CPU times for the problems described in section 5.1.2. 

Table 2 

Extrapolated CPU Times (minutes) for the HRV Formulated Problems (section 

5.1.2) 


Remote Computers Airborne Computers 



Micro 

VAXH 

MC 

5400 

CYBER 

750 

ALEXI 

6400 

SEL 

32/97 

T-xxx* 

(100-50%) 

MIL 

VAX 

HAWK 

T-xxx** 

(16-50%) 

POST 

Problem 1 

5 

2 

1 

1 

1 

0.03 

2 

3 

0.2 

Problem 2 

33 

12 

3 

6 

3 

0.14 

15 

20 

0.9 

ons 

Problem 1 

6 

2 

1 

1 

1 

0.03 

3 

4 

0.2 

Problem 2 

42 

15 

3 

7 

4 ■: 

0.19 

18 

25 

1.2 


* Note: Assumes 25 board advanced (second generation) transputer computer CPU (100 

transputers) with 50% parallelism achieved 

**Note: Assumes 4 board advanced (second generation) transputer computer CPU (16 

transputers) with 50% parallelism achieved 

The problems formulated in Section 5.1.2 were: 

Problem 1: This problem is similar to sample problem 2 above. An HRV reentry trajectory is 
sought which minimizes total heat flux. 

Problem 2: This problem generates a trajectory which accelerates the vehicle from Mach 5 to 
Mach 20 while minimizing the fuel required, keeping dynamic pressure within 
specified limits and stagnation heat flux below some maximums. 

The 50% percent parallelism figure for the transputer based computer system is based on 
the assumption that^on the average^the optimization algorithms can be recoded such that^on the 
average^>0% of the total CPU time available can be utilized when the optimization algorithms are in 
execution. In order to take advantage of parallelism, the optimization algorithms would have to be 
rewritten in the occam language. 
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Assuming that the current rate of computer throughput growth illustrated in Figure 7 is 
maintained, and assuming POST is implemented in an onboard computer for trajectory 
optimization, a five second solution to a significant trajectory optimization problem would be 
attainable in 1993 using on an advanced (second generation) transputer configuration. However, a 
qualified airborne computer based on this technology is not likely to be available until 1995-2000. 
The second generation transputer processor will be available in late 1988. The basis of this 
projection is die 0.9 minute solution time for the airborne T-XXX computer. Halving that number 
every year, we arrive at a 3-4 year period to reduce that solution time to 5 seconds. 

The advantages for transputer technology are clearly shown in Figure 9. Not only is 
throughput capability very high but cost is relatively low. In addition the number of nodes 
(processors) in a configuration is limited practically only by the user's ability to write software 
which takes advantage of the nodes available. 


J1K/MFLOP JIOK/MFLOP JIOOK/MFLOP JtOOOK/MFLOP 



PRICE IN THOUSANDS OF OOLLARS 


Figure 9: Transputers Provide Lots of Throughput for the Dollar 


5.1.5 Data Base requirements 

In addition to computer throughput, a second requirement for performing trajectory 
optimization in a real time replanning mode is the requirement to constantly (and in real time) 
change/modify the data base used in the POST and OTIS dynamic simulations. Both POST and 
OTIS have generic simulations preprogrammed which can be tailored to represent any flight 
vehicle. The OTIS simulation is a 3+ DOF+ simulation with pseudo degrees-of-ffeedom added. 
POST has two simulations: a 3 DOF version and a 6 DOF version. The simulations can be 
modified by a flight test engineer (FTE) working at a workstation if the programs are hosted in a 
ground based computer. 
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5.1.6 


Precise Test Trajectory Guidance & Control 


Once a trajectory is generated using OTIS or POST, the HRV must be precisely flown on 
the trajectory. Many trajectories may be able to be flown with adequate precision by the test pilot. 
Others may require a very high performance maneuver autopilot or flight test trajectory controller to 
fly the maneuver under fully automatic control. For example, during the flight envelope expansion 
flight testing, precise trajectory control particular during critical test conditions will be very 
important for three reasons: 1.) to assure the safe and efficient envelope expansion ; 2.) to avoid 
exceeding critical limits inadvertendy ; and, 3.) to provide precise test conditions for verification of 
predicted performance and technical data, i.e., aerothermal, propulsion parameters, structures, etc. 

If the test pilot is performing the maneuver, some type of display must be available to show 
tracking errors in some format so that the pilot can zero them. ILS type needles, or a pathway-in - 
the-sky type HUD display are possible. 

In the fully automatic mode, a number of design approaches can be taken to design the 
trajectory controller. As a general approach, we are suggesting a stochastic optimal state feedback 
tracking formulation be used. For specific instances wherein it is possible to define rather 
accurately the precise maneuver to be performed, a classical design approach for that specific 
maneuver might be preferred. More than likely, both design approaches to the trajectory controller 
should be employed even in parallel in some cases. 

Our experience indicates that remote computation is not required to implement such a 
controller even for HRV prototype testing. We recommend that the controller be implemented 
onboard in a general purpose flight test computer based on transputer technology. Guidance data 
generated from ground-based trajectory generators or optimization algorithms would have to be 
uplinked to the HRV to drive either the display or provide the autopilot input 


5.1.7 Data Link Requirements 

The data link requirements are discussed herein. With all all trajectory optimization except 
trajectory tracking done in remote computation we envision that the data link requirements for 
uplink and downlink to the HRV will not require significant expansion over what is currently 
available on the RAV system. 

UPLINK - Currently, the RAV facility uses two of its eleven message streams on 
the 1553 bus for uplink encoding at a maximum encoder rate of 97k bits/sec. The two streams 
consist of a 16 bit parallel data stream and a 32 bit parallel control stream. The uplink transmit rate 
is 256Hz with 21 bits/word and 18 words/frame. For each word, 16 bits are data bits and 5 
checksum bits. Similarly, each frame has 16 data words and 2 for control and synchronous 
information. 

Even though this current data rate will need to be vastly improved to support the HRV, they 
will only need to be improved slightly for remote trajectory optimization. Therefore, this function 
will not be the driving requirement for HRV uplink requirements. 

DOWNLINK - It is envisioned that the amount of data and the data rate necessary for 
performing will not increase significantly over current remotely augmented vehicle (RAV) levels. 
This data link would not have to be maintained continuously during flight testing, but it would be 
desirable to do so. Periods of noncoverage would mean some limitations imposed on real-time 
replanning during these periods, no data monitoring, no on-line data analysis. If it is possible to 
continue to provide communications during data link noncoverage, one could still do replanning 



based on predicted present position and operational state, however, uplink could not be used to 
automatically update the onboard tracker until the link is restored. 


5 . 2 Energy Management 

We define energy management as follows: knowing the following parameters about the 
flight vehicle at any given point in time: 

1 . the vehicle's kinetic energy, 

2. the vehicle's potential energy, 

3 . the vehicle's flight path vector, 

4. the stored energy state (fuel state - for each fuel type and/or engine if more than 
one are involved), 

5 . the vehicle's geographic position, 

6. the propulsion system status, 

7 . the vehicle's performance and aerodynamic characteristics, 

8 . all other restrictions on vehicle performance, 

9 . landing site locations and characteristics; 

where can the vehicle go in space (and land safely some place after going there), or where can it 
land. We define items 1 through 5 as the operational state of the vehicle. We include items 6 
through 8 in the vehicle's operational data base. 

Energy management is an operational and safety issue. In prior applications for vehicles 
such as the X-15, the space shuttle and the like, energy management has been used to determine 
power-off footprints for landing site alternatives. In these applications only the vehicle's kinetic 
and potential energy states, and the vehicle's aerodynamic performance characteristics (lift and 
drag) were required to calculate footprints. The footprints typically took the shape of cardioids 
with one axis dong the horizontal flight path vector. . 

Energy management for an HRV is a much more involved and computationally intensive 
issue. It is absolutely necessary to provide an on-line capability to determine where the vehicle is 
capable of going at any point in time in order to provide any flexibility whatsoever in mission or 
flight test replanning for contingencies. It is a necessary adjunct to trajectory optimization. It is a 
total waste of valuable time and resources, for example, to attempt to find an optimal trajectory to 
get to some final condition (such as a runway threshold at a specified landing site) if it is 
impossible from an available energy point of view to get there from here. Thus the analytic 
expression given by equation (1) is no longer valid. Propulsion effects must be included. In 
addition, energy management principles must be extended to cover not just landing site 
alternatives, but an available three dimensional volume of attainable space of which the cardioid 
previously referred to becomes a curved surface intersection of the the earth and the volume. The 
concept is shown in Figure 10. The volume should be computationally carried along with the 
vehicle. It changes shape continuously as a function of the vehicle's operational and data base 
state. 


We envision a continuous computation of this volume which is a function of not only a 
changing operational state but also a changing operational data base. The data base is shared by the 
trajectory optimization algorithms which are used to generate optimal trajectories between 
operational states within the volume. The AFMS system described in section 6.1 encompasses this 
energy management capability in addition to trajectory optimization. It is an integral part of 
preflight planning and in-flight replanning. 



Figure 10: An Attainable Space Volume is Continuously Calculated 


5.2.1 Requirements 

Energy management requires the employment on-line and during planning of algorithms 
which predict the total operating space which can be reached from any given operational state. It is 
implicitly understood (and must te taken into account in the algorithms) that one must be able not 
only to reach an operational point but to be able subsequently to land safely somewhere in order for 
the operational point to be considered as within the available operational space. For example, if we 
decide to accelerate from Mach 5 to Mach 20 along some operational line such as constant dynamic 
pressure, we must be confident that if we get there, we still have enough fuel left to land 
somewhere. Planning this in advance and simulating it in the NASA SIM facility is one matter, but 
suppose that a situation has arisen in which we would like to depart in-flight from the preplanned 
timeline due to some anomaly or an emergency. We must have a way of being able to predict the 
operational space available quickly. Trajectory optimization does not do this job efficiently. 

The requirements for energy management arise in just about all flight phases. In takeoff 
and ascent, for example, energy management is critically important to allow instant decisions on 
abort fields. In space shuttle and other space systems, abort field decisions are carefully planned in 
advance in a "canned" fashion. That is, if the vehicle is between a and b the abort field will be x 
for example. These decisions are determined by extensive ground simulation. Although such 
planning will also be done in HRV testing and operational employment, the use of on-line energy 
management computations will allow much more flexibility in replanning and added safety 
margins. It will allow a bridging of the gap between a vehicle which is very narrowly constrained 
to an extensively (and expensively) preplanned flight path and timeline (space shuttle) to a vehicle 
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which can be operated in a much more flexible way (as one would operate a high performance 
fighter). 


5.2.2 Normal Operation Example 

The sub-orbital cruise phase of the flight test program will consist of a series of flight test 
maneuvers planned, hopefully, with the help of a fully developed AFMS system (an advanced 
ATMS system discussed in section 6.1). Any number of circumstances could occur which require 
inflight replanning to be done. These circumstances might include a flight emergency requiring 
immediate recovery, a vehicle malfunction which dictates a change in flight plan not requiring an 
emergency landing, on-line data analysis which affects the flight plan (such as fuel consumption 
which is greater than planned requiring a real time replan), and a host of other circumstances. Real 
time replanning would require energy management calculations to immediately determine what it is 
possible to do and a trajectory optimization algorithm to optimize it 

For example, a sensor failure causes the loss of certain data which precludes performing a 
series of planned maneuvers, however, other maneuvers can be substituted which do not require 
this sensor, so that the flight is not lost. Substituting the new set of maneuvers for the remainder 
of the flight significantly alters the planned trajectory. An on-line replan must be done. This 
function cannot be presently done on airborne computers due to throughput limitations. 


5.2.3 Emergency Operation Example 

The same system functions in the event of a flight emergency. The most common type of 
emergency for which energy management will be of greatest assistance is one in which the vehicle 
must land as soon as possible. For example, the vehicle loses significant or total propulsion while 
at sub-orbit speed. The energy management algorithm displays a ground footprint which, 
hopefully, includes a suitable landing site. The trajectory generation algorithm generates an 
optimal trajectory to get there. It might be required that the maneuver be done in minimum time, or 
more likely, that the maneuver be done so as to maintain airspeed within some rather narrow range 
throughout the maneuver. Typically, one desires the end point of the maneuver to be at a "high 
key" over the desired landing point at maximum L/D airspeed. For these type vehicles "high key" 
is usually in excess of 40,000 feet AGL. 


5.2.4 Computation Requirements 

The computational requirements are discussed herein. As described previously, the energy 
management algorithm for continuously generating the attainable volume of space as a function of 
the vehicle's operational state and data base state is envisioned to be very computationally 
intensive. If we estimate the computational throughput required as being on the same order as the 
trajectory optimization algorithm, we will be in a conservative ball park. The basis of this is the 
following argument. We propose that an updated envelope should be calculated every second 
during flight. The calculation would include the boundary definition, graphical software to 
generate and display a graphical image of the attainable volume and a constantly updated data base 
of operational information derived from the envelope such as attainable landing sites. 


5.2.5 Data Link Requirements 

The data link requirements to support remote energy management computers are not 
expanded over those described in Section 5.1.7. 
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5.3 Autonomous Operations 


Manned operational hypersonic vehicles may need to operate autonomously, that is 
without communications or data links, for significant periods of time for certain military missions. 
Not having access to classified military requirements for such vehicles, we made the following 
assumptions about the requirements and associated flight systems functions for the purpose of this 
study: 


AUTONOMOUS CAPABILITIES 

1. Fly from mid altitude into low earth 
orbit (LEO) 

2. Rendezvous with a satellite in LEO 

3. Dock with a satellite 

- cooperative 

- non-cooperative 

4. Reenter and skip to a new orbit 


5. Reenter and fly to a designated recovery 
location 

6. Atmospheric flight to a specific location 
at a specific time 


FLIGHT SYSTEMS IMPLICATIONS 
Autonomous 3D navigation 

Precise 4D autonomous navigation and 
guidance 

Precise relative range, range rate and bearing 


Accurate orbital parameters, trajectory 
guidance, and energy management 

Accurate orbital parameters, trajectory 
guidance and energy management 

Precise 4D autonomous navigation, trajectory 
guidance and energy management 


It appears that all of the above could be demonstrated degree on the HRV using remote 
computation for the critical algorithms except the actual docking maneuver. One could even do a 
limited demonstration of docking guidance but not actual docking, which may not be necessary in 
the HRV flight test program. The trajectory guidance and energy management functions are 
similar, with respect to remote computational support, to the examples discussed in sections 5.1 
and 5.2. The principal new elements are the autonomous navigation, accurate orbital parameters 
determination and precise relative position determination for docking. An interesting and beneficial 
aspect of the remote computational approach is that several alternate implementations of these 
autonomous capabilities could^emonstrated on the HRV with essentially one set of core hardware 
and possibly different sensor sets. 


5.3.1 Example Autonomous Operation Systems Functions 


5. 3. 1.1 Autonomous Navigation 


The key feature of autonomous navigation is the use of onboard self contained precision 
position determination system, such as a stellar navigation system, to update the inertial nav 
system. It would be possibly to have only the star tracking system and inertial measurement unit 
(IMU) onboard, do the computations on the ground and data link the results to the HRV. 
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5.3.2 


Computation Requirements 


Trajectory optimizations and energy management must be performed onboard. We 
envision that operations will be simplified and restricted to place less computational demand on 
onboard computers. Trajectory optimizations for replanning, particularly for emergencies, will be 
possible. We might limit energy management calculations to footprint predictions only. 


5.3.3 Data Link Considerations 

Data link to ground facilities would not be increased over those discussed in Section 5.1.7 
to support autonomous operations demonstrations. 


6.0 Flight Test Management and Control 

A significant result of this study is the identification of the necessity to develop an 
automated flight management system to provide multiple levels of automated flight and system 
management for HRV. We suggest the development of a knowledge based automated flight and 
mission management system (AFMS). AFMS is envisioned as an extension of the Automated 
Flight Test Management System (ATMS)<7> , being developed by NASA for aiding the Flight Test 
Engineers during the HRV flight tests. ATMS is a flight test oriented system. The AFMS concept 
extends ATMS beyond flight testing to operational employment. The AFMS concept could be 
developed for the flight test program, extended, perfected and demonstrated in the flight test 
program, and then applied and extended further to cover both military and commercial 
planning/replanning in the vehicle's operational employment. 


6 . 1 AFMS Concept 

AFMS is envisioned as an integrated symbolic /conventional processing environment 
which provides several levels of automation for performing flight test planning and real time 
replanning, mission planning and real time replanning, trajectory guidance and control, trajectory 
optimization, trajectory generation, energy management, flight system management and data 
system management. AFMS provides the total man-machine interface between mission/flight test 
control personnel, the flight vehicle and all remote computational facilities in addition to managing 
all autonomous operations. AFMS represents the highest level of automated flight system 
management for NASP and allows multiple levels of human interface, intervention, observation 
and supervision. The concept is shown in Figure 11. 

The AFMS concept is discussed in the context of trajectory guidance and control for 
illustration purposes. OTIS and POST would be totally integrated into die ATMS system to form 
the AFMS environment. Research engineers would use AFMS with OTIS and POST to generate 
optimized flight test maneuver subproblems for a number of flight test maneuvers. The Fi t's 
workstation would allow the FTE to choose between these subproblems, choose specific flight 
conditions and define a trajectory by optimizing within a subproblem. That is, the FTE would not 
be working with raw OTIS or raw POST formulating. That work would be done by research 
engineers. The FTE would be constrained by subproblem definitions already set up by the 
research engineer. Within those selectable definitions the FTE would perform optimization for 
planning or replanning in flight. 


23 



FLIGHT TEST ENGINEERS 



Figure 11: AFMS Concept 

The FTE workstation, the simulation validation workstatioivand the flight system concepts 
developed for ATMS would be extended to AFMS. In essence, AFMS would provide knowledge- 
based, expert system assisted supervisory management of a number of algorithmic tools to perform 
trajectory optimization, data analysis, data reduction, flight and data monitoring, weather 
monitoring, and other functions to aid the FTE, test conductors and test pilots in conducting 
successful flight tests which maximize available flight time utilization, flight resource utilization 
and minimize flight testing costs. 

The AFMS system using the knowledge-based expert system planner, the energy 
management algorithm, the trajectory optimization algorithm, the flight test trajectory controller and 
the 3 DOF+ vehicle simulation is used to create flight plans and trajector ies. The plann er 
supervises the coordinated use of these algorithms under the oversight of the FTE. The FTE is 
allowed to interact with the system as it is performing the real time replanning function to provide 
his guidance, input and approval. In essence, computational power and an advanced, highly 
integrated set of conventional and knowledge-based algorithms are used to perform in a semi- 
automated fashion, the job several FTE's (and the test conductor) would be doing in a near panic 
mode and very inexactly, when faced with a flight or data anomaly. 
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6.2 AFMS Development 

We envision AFMS to be developed in three phases. First, ATMS would be fully 
developed as a flight test engineer's flight test planning, replanning and monitoring tool for HRV 
flight testing. Second, AFMS would be completely developed as a natural extension of ATMS and 
used to support NASP flight testing. Third, AFMS would be expanded to support NASP mission 
management in the operational environment. 

6.3 AFMS Architecture 

A suggested AFMS architecture is shown in Figure 12 as implemented in SUN 
workstations. 




Figure 12: AFMS Architecture 

We envision a networked system of computers to host AFMS based on SUN workstations. 
We envision that the man-machine interface to the system with all its associated display and 
interface software is hosted in a minicomputer workstation such as a SUN 3/50 on a customized 
communication network with other computers in the AFMS system. By the same token we 
envision that the trajectory optimization algorithms, flight test trajectory controllers and simulations 
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be also hosted on separate workstations on the same customized communication network in the 
AFMS system. 

We envision that each workstation would require a transputer interface to a transputer 
"box" with an expandable number of transputers to increase the computational throughput of the 
workstation. As described in section 5.1.4, the computational throughout required to support 
trajectory optimization is 400 MFLOPS. This is attainable with a SUN 3/50 with an adjunct 
transputer system of 128 transputers provided full parallelism is realizable. This assumes we 
would like to be able to solve a significant optimization problem in 5 seconds of CPU time. A 
equivalent system would easily handle the energy management function. 


6.4 Example Problem Formulations 

This section contains several examples of uses of the proposed AFMS system as an aid to 
conducting HRV flight testing. 


6.4.1 Flight Test Planning 

An HRV type vehicle will be expensive to fly and always fuel critical. Efficient flight 
planning will be crucial to keep flight test costs under control. AFMS provides this capability with 
a dedicated workstation environment independent of the NASA SIM facility. Like ATMS, AFMS 
would allow the FTE the ability to string together in the most fuel efficient way a series of flight 
test maneuvers. AFMS would not only allow preprogrammed flight test maneuvers to be ordered 
efficiently but also would the use trajectory optimization algorithms to generate optimum paths. 
Contingency plans could also be easily generated. 

Flight test planning is done with the aid of an expert system planner as demonstrated in the 
ATMS prototype system.. The planner includes a set of rules for ordering maneuvers in the most 
fuel efficient or time efficient way. The system integrates knowledge-based expert systems with 
conventional trajectory optimization, controller and simulation algorithms. 


6.4.2 Flight Test Validation 

As with ATMS, AFMS contains a communication interface between the workstation 
computer and the NASA SIM facility to validate flight plans generated with the workstation in real 
time piloted simulation. Actual flight test is then just one step away: a substitution of the HRV 
flight vehicle for the 6 DOF simulation. 


6.4.3 Flight Test Monitoring 

AFMS allows automated monitoring of downlinked flight data from the HRV vehicle and 
tracking data from range facilities. Flight data from specific flight test maneuvers can be analyzed 
in real time and decision made with the aid of an expert system monitor on the quality of the data 
obtained from the maneuver. Health Monitoring of vehicle systems can also be done. 


6.4.4 Flight Test Replanning - - 

In the event that the flight test monitor shows some test or time line anomaly or an 
emergency, real time replanning can be done automatically. The expert system replanner efficiently 
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uses energy management calculations and trajectory optimization algorithms to formulate replans 
quickly and with improved accuracy compared to decisions arrived at by FTE's under time 
pressure. The concept utilizes the replanner not as a replacement for FTE involvement in the 
replanning process but as an aid to improve their judgement under time pressure. The system 
allows FTE's to be involved at a higher management level in this replanning process thereby 
improving the quality of decision reached and reducing the risk of making incorrect replanning 
decisions. 


6.4.5 Flight Envelope Expansion 

The following problem is an example of envelope expansion. The technique requires on- 
line data reduction and analysis to correct the stability and control parameters in the aerodynamic 
simulation to match the responses to control inputs at each test point (Mach number). The 
simulation is then extended to the next flight condition and simulated responses to control inputs 
are obtained and analyzed prior to actually flying the aircraft to the next data point. Trajectory 
optimization is required in real time with the constantly changing simulation parameters to derive 
new trajectories between the data points. This is a case of the HRV trajectories being potentially 
much more complicated with more constraints to be obeyed than in the case of simple level 
accelerations between data points with a high performance fighter. 

This problem involves stringing together a series of flight test segments which must be 
performed with minimum fuel subject to the following conditions and constraints: 

a. Dynamic pressure equal to some constant unless constraint b (below) is violated, in 
which case dynamic pressure is to be greater than some minimum. 

b. Stagnation point heat flux is less than some maximum. 

c. The following Mach profile is commanded: 


1) 

t = to 

M = 5 

2) 

to -> ti 

accelerate to M 

3) 

ti -> t 2 

M = 6 + 0.05 

4) 

t2 -> t3 

accelerate to M 

5) 

t3 -> t4 

M = 8 + 0.05 

6) 

4 -> t5 

accelerate to M 

7) 

*5 -> *6 

M = 10 + 0.05 

8) 

t6 -> t 7 

decelerate to M 


6.4.6 Trajectory Generation 

We envision trajectory generation as being performed in the AFMS system. Trajectory 
generation differs from trajectory optimization in that trajectories are generated without the use of 
an optimization algorithm. This is the way it is currently done in the ATMS prototype system. 
Flight test maneuvers are preprogrammed to force the vehicle to follow prescribed state variable 
conditions to reproduce for example, a windup turn. Closed loop control is exercised over 
obser ved states to produce the maneuver specified. The ATMS Flight Test Trajectory Generator 
(FTTG) includes capture and exit segments to capture the desired trim condition and restore level 
flight after the maneuver. 
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6.4.7 


Trajectory Optimization 


Trajectory optimization is an alternative form of trajectory generation which we view as 
absolutely required for HRV flight testing. For example, trajectory optimization is required to 
compute reentry trajectories which are optimal from an aerodynamic heating viewpoint. The 
optimal policy must consider the design of the thermal protection system and the best way to 
employ it during reentry. For example, in space shuttle reentry it is best to maximize the heat flux 
as early in the reentry as possible. 

Since fuel will always be critical in HRV flight, minimum fuel trajectories will be sought 
routinely. Merely transitioning from one flight condition to the next, a trivial maneuver in a high 
performance flight test airplane, will in all likelihood require a minimum fuel trajectory optimization 
solution. 


6.4.8 Energy Management 

Continuous energy management calculations are required to assure that test conductor 
personnel, flight crew and FTE's know at all times where the HRV is capable of going from its 
present position considering its operational state and fuel status. This is important to allow 
continuous awareness of immediately available landing sites. It is also important to replanning so 
that a replan is not suggested from which safe recovery to a landing site is not possible. 

The implementation of this level of energy management will allow the HRV to be flown in 
both a flight test and operational mode more similar to that of a high performance airplane than, for 
example, a space shuttle. During space shuttle flight (and for that matter all previous space 
vehicles) flight plans are very seldom altered from those planned and rigorously simulated prior to 
flight. Replanning is a major effort and is done with extensive human resources and with great 
care. Ground simulation is used extensively in replanning and the activity takes a lot of time. 
AFMS imposes automation on some percentage of the effort. An energy management algorithm 
provides the necessary tool to enable replanning to be done quickly. Without the algorithm, 
trajectory optimization could be far more time consuming because many optimization attempts 
using impossible sets of end conditions would fail. 


6.5 The Extension of AFMS to Operational Employment 

AFMS is a natural operational employment tool for planning, monitoring, controlling and 
supervising the operational flights of HRV type operational vehicles. Extending the AFMS flight 
test system to military or commercial operations would provide a cost effective way of developing 
and testing not only the vehicle but also an automated tool for employing it 


6.6 Digital Performance Simulation (DPS) Studies 


DPS( 16 ) was hosted on a MicroVAX II and on the TI EXP-LX at SPARTA to conduct 
energy management studies. Simplified Keplerian dynamics were added in addition to ] Generic 
Hypersonic Computer Simulation Aerodynamic Model (3 DOF) (GHAME). The Keplerian 
dynamic modification consisted of adding a correction term into a gravity calculation to reduce "g" 
by centrifugal force. No modifications were made to include a round earth. Thus, any results 
obtained from this simulation are valid for short flight segments only, (include other changes made 
to accommodate HRV model). A number of trajectories were generated using DPS maneuver 
options 1, 2, 3, etc. 
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It quickly became apparent in this effort that DPS was not an appropriate tool for HRV 
trajectory studies of any type. DPS is a true 3 DOF simulation without any pseudo degrees-of- 
freedom added for incorporating rate limits. As such it is not suitable for inclusion in an 
optimization routine for trajectory generation. Our conclusion from this study was that DPS is not 
suitable for inclusion into the AFMS structure: that OTIS and POST are much more suitable and 
capable for any trajectory studies in the HRV program. 


6.7 ATMS Demonstration With HRV Dynamics 

The GHAME 3 DOF simulation was integrated into the ATMS system developed under 
separate contract. The HRV appears as a selectable flight vehicle under the AIRCRAFT menu. 
The only other working selection on this menu is the HIDEC F-15 which was used for all the 
ATMS development and demonstrations. A limited demonstration was developed showing a 
hypothetical abort situation from an altitude of 200,000 feet over Lancaster and a subsequent 
landing at Edwards. DPS (modified for the HRV) was used to generate the trajectory. Trajectory 
optimization was simulated. 

The demonstration illustrates how a trajectory optimization algorithm triggered by the 
ATMS flight test monitor expert system could be utilized to generate a zero thrust trajectory. The 
trajectory generated would be displayed on the ATMS monitor for the FTE and test conductor's 
observation. Then upon receiving approval in response to a prompt, the system would trigger the 
tracker/controller to follow the trajectory generated, or give guidance commands to the test pilot 
through ILS type needles or a pathway-in-the-sky HUD display. The pilot could then fly the 
maneuver manually. 


6.8 AFMS Example Problems 

Two example programs are formulated in the following sections which illustrate how 
AFMS would be used in HRV flight testing. The extensions of this to production system 
operations are obvious. 

6.8.1 Example Problem in the Normal Test Mode 

In this example we envision an HRV in the midst of performing envelope expansion at 
some test altitude. The remaining test plan after the envelope expansion consists of a descent to a 
lower altitude, a series of speed-power points and, finally, a descent to a landing. Let us suppose 
that we encounter a higher than expected fuel consumption during the envelope expansion 
maneuver. The higher fuel consumption dictates a landing earlier than planned. The challenge is 
to use the remainder flight time as efficiently as possible considering the currently planned 
remaining maneuvers and their relative priorities and maneuver conditions, and the alterations 
required to the ground track to accomplish the earlier landing. Without AFMS, we are limited to 
exercising one of a set of well preplanned contingencies. The more flexibility we want, the more 
contingencies we have to preplan and validate individually in simulation. With AFMS we are able 
to replan in flight without excessive contingency preflight planning. In addition, we realize 
considerable improvement in mission flexibility. Also, by validating the AFMS system in 
simulation instead of each individual contingency plan for each individual flight test, we save 
considerably on engineering and simulation time. The increase in flexibility attainable and the 
decrease in the amount of preflight contingency planning required both reduces the cost of flight 
testing considerably while increasing operating safety margins. 
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In Table 3 a sample timeline of events is given for the formulated problem described in the 
previous paragraph. 

Table 3: Replan Timeline - Fuel Consumption Problem 


Time (sec) 

Event 

0 

Fuel anomaly discovered by AFMS monitor expert system. 
System alerts FTE with message. 

0+ 

AFMS recommends that a replan be initiated. 

2 

FTE initiates replan using AFMS interface (keyboard 
response to a prompt). FTE selects planning parameters 
or defaults. 

2+ 

AFMS starts planing function. Monitor function is 
temporarily suspended. 

3 

Planning expert system: 

- uses management algorithm to calculate effect on 
landing site if any, 

- uses planer rules to determine priorities between 
cutting off envelope expansion maneuver or 
limiting speed-power points, 

- uses trajectory optimization algorithm (with 3 DOF+ 
simulation) to truncate maneuvers in accordance with 
planner priority and to make alterations to remaining 
trajectory so that the best use is made of the remaining 
flight time, 

- uses energy management algorithm again to confirm 
trajectory optimization solution is feasible. 

12 

AFMS uses 6 DOF simulation and FTTG/C to validate trajectory. 
Trajectory is displayed on the AFMS map and timeline displays. 

15 

FTE approves replan and instructs AFMS to exercise the plan. 

15+ 

AFMS issues revised plan to FTTG/C. Altered guidance commands 
begin driving pilot displays for manual control or controller for 
automatic vehicle control depending on the mode of operation 
previously selected. 


The original and altered timelines are shown in Figure 13 assuming that the planner chose to limit 
the envelope expansion maneuver as a result of an anomaly in fuel consumption noted at point A. 
The planning activity is shown completed at B. 
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ALTITUDE 


ENVELOPE EXP. 



Figure 13: Replanning is Accomplished Within 15 Seconds 


6.8.2 Example Problem in the Emergency Mode 

In this example, we envision an HRV in the midst of performing envelope expansion at 
some test altitude. The remaining test plan after the envelope expansion consists of a descent to a 
lower altitude. The remaining test plan after the envelope expansion consists of a descent to a 
lower altitude, a series of speed-power pints and, finally, a descent to a landing. Let us suppose 
that a flight control computer malfunction occurs. Prudence dictates an immediate precautionary 
landing at the nearest available and suitable landing site. Without AFMS, we are limited to a few 
well planned contingencies. We will have planned abort sites all along the preplanned trajectory. 
Any replanning as described in Section 6.8.1, is severely limited because of the necessity to remain 
close to the preplanned trajectory so as not to invalidate the contingency planning for emergencies 
such as this one. AFMS relieves this requirement considerably and provides improved flexibility 
as a result. 

In Table 4, a sample timeline of events is given for the formulated problem described in the 
previous paragraph. 


Table 4: Replan Timeline - Emergency Abort Problem 


Time (sec) 

Event 

0 

Flight control computer fails. 

2 

FTE initiates replan by telling AFMS to immediately plan landing at 
the nearest site in minimum time. 

2+ 

AFMS starts planning function. Monitor function is temporarily 
suspended. 

3 

Planning expert system: 

- uses energy management algorithm to determine closest 
landing sites, 

- uses planer rules to select best of available lading sites, 

- uses trajectory optimization algorithm (with 3 DOF+ 
simulation) to determine optimal path to chosen landing 
site, 

- uses energy management algorithm again to confirm if 
trajectory optimization solution is feasible. 

10 

AFMS uses 6 DOF simulation and FTTG/C to validate trajectory. 
Trajectory is displayed on the AFMS map and timeline displays. 

12 

FTE approves replan and instructs AFMS to exercise the plan. 

12+ 

AFMS issues revised plan to FTTG/C, Altered guidance commands 
begin driving pilot displays for manual control or controller for 
automatic vehicle control depending on the mode of operation 
previously selected. 


The original and altered timelines are shown below. Point A denotes the pint of system failure 
detection. The planning activity is shown completed at B. 


ALTITUDE 



Figure 14: Replanning is Accomplished Within 12 Seconds 
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7.0 Unmanned Operations 


Although the principal focus of the study was on manned vehicle flight, we were asked to 
consider the additional implications on remote computational support for unmanned operations. 
Unmanned operations are defined as operations with no flight crew onboard and the vehicle 
operates under the supervision/control of a ground based system and/or pilot, i.e. remotely piloted 
vehicle (RPV). 


7.1 Requirements 

Unmanned operations require, at a minimum, electronic interfaces to the vehicle systems 
that a crew member would have provided. It's generally held that a manned HRV would have 
most if not all of the systems automated and the crew could operate principally as a monitor and 
take over in an emergency. If that's the case one might think that going to unmanned operations 
would be simple. It could be if a higher program risk is acceptable. One could use the RPV mode 
as the emergency mode to backup the onboard automated systems. What one looses is the infinite 
adaptable and reasoning of the human insitu that is most beneficial in the emergency situation. It's 
virtually impossible to reproduce the flight and systems environments adequately on the ground for 
a pilot to be as effective as in flight. That means that it's more likely that an emergency could arise 
that an RPV pilot could not adapt to fast enough to avoid a critical situation; hence there would be 
more risk to the program. 

We will assume that an RPV pilot would be used and in a similar manner as an onboard 
crew. Information would be required on the ground for monitoring and possibly control all vehicle 
systems including: 

1 . Propulsion system; 

2. Right path control; 

3. Fuel system and fuel transfer; 

4. Navigation system; - 

5. Configuration control; 

6. All onboard sensors; 

7 . All onboard avionics; 

8. All subsystems; 

9 . Instrumentation; and, 

10. Others 

Under normal operating conditions, this information would be telemetered to the mission control 
center even for manned vehicle operations for monitoring purposes. The remote computations for 
supporting flight systems functions discussed in the previous sections would be used. Trajectory 
guidance commands would be uplinked and tied directly into the autopilot as well as displayed to 
the RPV pilot Similarly with other functions. 


7.2 Systems Requirements and Impact 

We believe the following additional functions would have to be added to the vehicle if it's 
unmanned: 

1 . Benign emergency autopilot modes in case of a data link failure; 

2. Onboard systems health monitoring and critical action systems; 

3 . Backup RPV operating mode, possibly from an airborne platform. 
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7.3 Operational Issues and Risks 

The risks associated with creating full dependence on automated systems with no onboard 
flight crew backup available seem to far outweigh the potential benefits achieved for this type of 
flight vehicle. The risks include loss of the vehicle due to: 

1 . Loss of data link; 

2. An emergency set of conditions not anticipated for which onboard systems cannot 
provide required information to troubleshoot; and, 

3. A combination of 1 and 2 above. 

These risks increase the probability of loss of the vehicle to the point of causing restrictions 
on airspace use by agencies such as the FAA. Political considerations and public perception might 
prohibit the use of continental airspace or for that matter, overland flight anywhere. 


8.0 Experimental Vehicle Implications 

The implications on the vehicle design and cost of using remote computational support to 
perform the flight management functions discussed herein as opposed to performing these 
functions onboard are difficult to assess to any degree of accuracy. The following considerations 
are germane: 

1 . The design and development of an onboard computing system to perform these functions 
for the first HRV will be very expensive and very technically risky. 

2. The development of a ground based environment to support remote computation as 
described herein is relatively inexpensive and of low technical risk. This is because the 
essential components of the system are already in place and the concept of remote vehicle 
control has been exhaustively flight tested and used routinely by NASA Ames Dryden for 
ten years. NASA is already developing an automated flight test management system which 
has all of the components required. The Phase I ATMS system has been demonstrated in 
simulation. 

3. Vehicle weight considerations are considered minimal. There appears to be no significant 
difference between supporting remote computation with its associated data link equipment 
and adding a very capable computer system to perform all computational functions 
onboard. 


9.0 Conclusions 

In this section we present the conclusions reached in Part II of the contract concerning the 
advantages and requirements for remote computational support for HRV flight testing. 

1 . It is feasible and beneficial to perform the trajectory optimization, energy management and 
trajectory generation computations for the HRV flight test program with remote computers i 
the mission control center and data links to the HRV. The following benefits were 
concluded: 

a. Although it should be possible to build a computer architecture capable of 
performing realistic trajectory optimization and/or energy management onboard in 
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real-time based on 1993 transputer technology, there is some program risk of getting 
such a computer flight qualified before the late 1990's. 

b. Ground-based implementation allows a much more complete modeling of the HRV 
performance and the atmospheric conditions that is likely with onboard computers 
which would be available in the mid- 1990 time period. 

c. Ground-based implementation provides greater flexibility for investigating several 
alternate optimization and guidance techniques with little or no impact on the vehicle 
and vehicle development schedule. Even algorithms specifically designed for 
onboard implementation could be evaluated by this method. Also, these software 
packages will be much less costly to develop and validate since they do not have to 
be flight qualified. 

d. The capability to test onboard trajectory optimization and energy management 
algorithms using ground-based computers would inherently be available in an 
automated flight management system discussed in Conclusion 2. 

2. An automated flight management system (AFMS) is highly desirable and beneficial for the 
HRV flight test program. The key benefits identified are as follows: 

a. Significant improvement in flexibility during flight testing leading to more efficient 
use of flight time especially in the event that changes in a flight plan are required to 
accommodate emergencies or time line anomalies. 

b . Significant decrease in required contingency preflight planning and associated flight 
plan validation simulation. 

c. Reduced cost of flight testing due to the savings realized in a and b above. 

3. Transputer technology provides a very cost effective potential for both onboard real-time 
flight systems functions and extensive ground-based computations necessary for trajectory 
optimization and energy management. The key factors and benefits identified area as 
follows: 

a. Transputers are easily parallelized into configurations of an unlimited number of 
mods (processors), thus, providing expandable parallel processing capability. 

b. Transputers support occam, a language and operating system which supports 
parallel processing. 

c. Transputers provide very high throughput at very low cost. 

d. Transputer- based computers are configurable in terms of size and weight and, as a 
result, are natural candidates for airborne applications. 

e. Transputer technology is being developed for even higher throughput devices. 

4. Autonomous operations can be demonstrated using remote computation support. Remote 
computation can be used to demonstrate many alternate implementations using ground- 
based computers. In terms of onboard computational support required for autonomous 
operations, the three previous conclusions apply. It may be desirable to provide less 
capable optimization and energy management algorithms onboard for autonomous 
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operations. For example, energy management might be restricted to provide landing site 
availability and reachability only as opposed to a full replanning capability. 

5. Unmanned operations of a HRV disguised for manned flight are possible but are highly 
discouraged for HRV missions. Besides the requirement for providing quad redundant 
data links for all flight management and system monitoring functions, the political and 
public implications of flight testing and operating an unmanned HRV vehicle over the 
continental United States and other public lands are enormous, particularly when the public 
realizes that most of the time the vehicle is at suborbital velocities which implies that many 
emergencies may force the vehicle to find a place to land quickly. 


10.0 Recommendations 

The following actions are recommended as a result of this study: 

1 . Use remote computation in HRV flight testing to: 

a. provide the functions described herein without attempting to build an expensive 
onboard system in the first vehicle, 

b. expand significantly the operational flexibility of the vehicle, 

c. reduce significantly the risks attendant with HRV flight testing. 

2. Aggressively pursue the development of ATMS technology to HRV flight testing (AFMS). 

3. Continue to investigate the application of transputer technology to both an onboard flight 
research computer and as augmentation to NASA Ames-Dryden's remote computation 
capability. 
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